# TypeScript 工程化：代码检测
很多人可能会疑惑，TypeScript 自带静态类型检测，为什么还需要代码检测工具？
实际上 TypeScript 主要用于检查类型和语法错误，而代码检测工具主要用于检查代码风格，其作用是统一团队的代码风格，便于项目维护、降低沟通或者阅读成本。
相比于 TypeScript 更关注类型，代码检测工具更关注代码风格，比如：
- 缩进应该是四个空格还是两个空格？
- 是否应该禁用 var？
- 接口名是否应该以 I 开头？
- 是否应该强制使用 === 而不是 ==？
# 代码检测工具选择
TypeScript 的代码检测工具选择上一直是二选一的问题，他们分别是 TSLint 和 ESLint。
在很长一段时间里，TypeScript 代码检测工具一直是以 TSLint 为主，相比于在 JavaScript 领域独领风骚的 ESLint，它对 TypeScript 的支持更加友好。
但是由于一些性能问题 TypeScript 官方支持了 ESLint,随后 TSLint 作者宣布放弃 TSLint:
结果也比较明显，虽然现在现存的 TypeScript 项目依然是以 TSLint 为主，但是如果面向未来的话，ESLint 显然是我们的首选。
随着 TSLint 被作者放弃维护，加之 TSLint 作者加入 ESlint 为其提供 ESLint + TypeScript 的优化，实际上 ESLint 的短板在逐渐被补齐，加上 ESLint 一向固有的优势， ESLint 单从强大程度依然是压过 TSLint 的。
# ESLint 兼容性问题被解决
由于 TSLint 直接寄生于 TypeScript 之下，他们的 parser 是相同的，产生的 AST 也是相同的。
因此 TSLint 的 bug 更少，对 TypeScript 支持更友好，而 ESLint 的御用 Parser 是基于 ESTree 标准的，其产生的 AST 与 TypeScript 并不相同。
所以 ESLint 需要做额外的兼容性工作来兼容 TypeScript，但是这个难度可想而知，ESLint 做的一直不够好，但是目前 TypeScript 官方支持了 ESLint，与 ESLint 共同发布了 typescript-eslint 来解决兼容性问题。
甚至 TypeScript 本身就作为测试平台，在兼容性方面 ESLint 的进步是实质性的，毕竟 typescript-eslint 这个 parser 的主要贡献者就是 TypeScript 团队本身。
# ESlint 的优势
在 TypeScript 官方团队着手帮助 ESLint 解决了棘手的兼容性问题之后，ESLint 的优势就更加明显：
- 可配置性更高：ESLint 的配置规则远多于 TSLint，ESLint 的可配置规则超过 250 个
- 更活跃的生态：基本上需要开发者能想到的插件，在 ESLint 中都能找到，而基于这些插件我们也很容易进行魔改或者拓展
举个简单的例子，在 ESLint 中有一项配置叫做max-params，它能检测一个函数的参数数量，我们可以设定参数数量的上限，限制一个函数引入过量的参数引起不必要的复杂度。
function foo (bar, baz, qux, qxx) { // four parameters, may be too many
doSomething();
}
而这个功能在 TSLint 中是无法实现的。
# ESLint 的使用
我们简单学习一下 ESLint 的使用方法
# ESLint 的安装
# 全局安装
如果你想使 ESLint 适用于你所有的项目，建议全局安装 ESLint。
npm install -g eslint
